Container string hosts

Container hosts

Custom containers always have a host. The player normally opens the custom container by interacting with the host. Furthermore, the contents of the container are usually stored at the host. The host is usually a block or a pocket container. In the case of a block, the player can open it by right-clicking the block or by left-clicking it while sneaking. In the case of a pocket container, the player can open it by right-clicking with the pocket container in their hand.

String hosts

A special type of container hosts supported by this plug-in are string hosts. When using a string host, the container is associated with a string (basically a small piece of text in programming/scripting jargon) rather than with a block or pocket container. String hosts can only be used by the /kci container command, Skripts, and Denizen scripts. In combination with scripting, string hosts can be very powerful. However, they are not very useful without scripts.

Opening string hosts

There are 3 ways to open a string host:

By using a command: /kci container open container_name string_host player_name
By using Skript: player opens kci "container_name" at "string_host"
By using Denizen: kci_container player opens container_name at string_host

In case you use the command, you need to have the right permissions. If you are opening the container yourself, you need at least 1 of the following permissions:

customitems.containercommand.openself.*.*
customitems.containercommand.openself.container_name.*
customitems.containercommand.openself.*.string_host
customitems.containercommand.openself.container_name.string_host

If you use the command to let someone else open a custom container, you need to have the customitems.containercommand.openother permission.

Choosing the container storage mode

If you wish to use string hosts for a custom container, it is usually best to choose one of the following storage modes:

NOT_PERSISTENT if you want the container to drop all items when the player closes it. In this case, it doesn't really matter which string host you choose since no items can be stored.
PER_LOCATION if you want the container to store its items at the string host and you want all players to share the same container inventory.
PER_LOCATION_PER_PLAYER if you want the container to store its items at the string host and you want each player to have their own container inventory.

Using the other storage modes beats the purpose of string hosts because the container inventory will be shared between distinct string hosts.

Choosing the string host

If you have chosen the PER_LOCATION or PER_LOCATION_PER_PLAYER storage mode, each distinct string host will have its own container inventory. If you have chosen another storage mode, all string hosts will share the same inventory (and thus it doesn't matter which string host you pick, so you can skip this section). Some examples of string hosts are given below:

Using 1 string host per container

If you use only 1 string host per container, it doesn't matter which string you choose. The result will basically be an 'ender custom container' that players can open via commands or scripts. You could use this for an extra ender chest or for some kind of 'wiki'.

Using faction names as string hosts

If you have a faction server, you could use the names of the factions as the string hosts. This will result in every faction having their own custom container inventory that members can access via commands or scripts. If you use commands, I recommend using permissions to ensure players can only open the container inventory of their own faction. You could use this as a shared faction storage or a custom container with powerful container recipes with long durations (so every faction can only perform 1 powerful recipe at the same time and needs to choose wisely).

Using entity UUIDs as string hosts

In Minecraft, every entity has its own UUID, which you could use as string host. This will result in having a container inventory per entity. This could be used to assign custom containers to animals, NPCs, and minecarts. This could probably be useful in combination with Citizens.

More ways

This was just a small list of ideas to give you some inspiration. There are countless other string hosts you can use and you can probably come up with other useful ways if you take some time to think about it.

Cleaning up

When a regular custom container is hosted by a block, and that block gets broken, the container is automatically destroyed, and its items will be dropped on the ground. If you use string hosts, there is no such clean-up mechanism: the container inventory will remain in memory (and on disk) until you destroy it with a command or script. Depending on your usecase, this may or may not be desired. (For instance, keeping faction inventory indefinitely is probably fine, but entity inventories should probably be cleaned up when the host entity dies. In this case, you could use a script that destroys the containers of each entity when they die.)

Just like opening a container at a string host, there are 3 ways to destroy a container at a string host: commands, Skripts, and Denizen scripts. Furthermore, you can choose whether you want the inventory content to be dropped or destroyed. To destroy the inventory contents, use:

This command: /kci container destroy container_name string_host
This Skript: destroy kci "container_name" at "string_host"
This Denizen script: kci_container destroy container_name at string_host

If you would like to drop the inventory contents at a given location, use 1 of these instead:

This command: /kci container destroy container_name string_host world_name x y z
This Skript: destroy kci "container_name" at "string_host" and drop its items at drop_location
This Denizen script: kci_container destroy container_name at string_host and drop items at drop_location